1. Technical Field
The present invention relates in general to a system and method for integrating applications based upon a user's actions. More particularly, the present invention relates to a system and method of integrating portlets so that source portlets are able to automatically provide data to target portlets.
2. Background Art
The portal market is one of the fastest growing markets of computer software. A portal, in the context of a preferred embodiment of the present invention, may be defined as an application that provides a secure, single point of interaction with diverse information, business processes, and people, personalized to a user's needs and responsibilities. A portal, or “Web portal,” is a Web site or service that offers a broad array of resources and services, such as e-mail, forums, search engines, and on-line shopping malls. Portals are typically accessed by a user on the Internet using a software application, such as a Web browser. A Web browser, or “browser,” is a software application used to locate and display Web pages. Two popular browsers are NETSCAPE NAVIGATOR™ and MICROSOFT INTERNET EXPLORER™. Both of these are graphical browsers, which means that they can display graphics as well as text. In addition, most modern browsers can present multimedia information, including sound and video, though they often require plug-ins in order to handle some formats.
The demand for portals drives rapid development of new technologies by different portal vendors in order to place their products in advantageous market positions. Not surprisingly, portals have evolved to their current state from a more primitive beginning. Originally, portals were mainly used as access points to different information sources with content being chosen by the portal operator. Next, portal customization provided users with the ability to choose the content that was displayed on the user's view of the portal using a Web browser. In this phase, the user was able to select information according to the user's interests and retrieve information related to his or her interests more expeditiously. Customized information delivery led to the introduction of business, or corporate, portals. Business portals were introduced to provide intra-business data within an organization.
The ongoing evolution of portals also left its footprint in the architecture of portal products. At first, portal-like products were delivered as pre-packaged applications that could be installed out of the box and included standard applications, which provided the portal functionality. As new applications were needed, vendors extended their products in order to satisfy requirements of the new applications. Due to the use of proprietary designs, portal vendors added exclusive functionality to their portals, tying the success of a portal to the applications that the portal included. This led to the decomposition of monolithic portal structures and the creation of portal frameworks.
Portal products offered today employ architectures whereby the portal itself only implements standard functionality, such as security, authorization, authentication, aggregation, caching, user management, enrollment, rendering, and the like. The portal provides the infrastructure to integrate other application components. A typical embodiment of this type of architecture includes APIs for integrating applications so that applications from different vendors can be used so long as they match the portal product's API. According to current computing jargon, these applications are commonly called “portlets.” Other synonyms for “portlets” in current use in the art include ‘iViews’ (a term utilized by SAP AG of Walldorf, Germany) or ‘web parts’ (a term utilized by Microsoft, Inc. of Redmond, Wash.).
Portlets are components that can be added to portals and are designed to run inside a portal's portlet container. Portlets may provide different functions ranging from simple rendering of static or dynamic content to application functions such as e-mail, electronic calendaring, and the like. Portlets are invoked indirectly via the portal infrastructure and produce content that is suited for aggregation in larger pages.
While portlets allow separation of application components from each other and from the underlying portal, a challenge of using portlets is the difficulty in transmitting data that appears on one portlet to another portlet. For example, if one portlet displays orders for an organization and another portlet displays details for orders, vendors would have to “couple” the portlets to allow the user to send data from one portlet to another. In a business system, many portlets may be driven from the same pieces of information, such as order numbers, account numbers, and customer numbers. Closely coupling portlets to one another increases development requirements and maintenance of each portlet. In addition, coupling portlets may require activation of each of the coupled portlets even though the user only wants to view a subset of the coupled portlets.
In commonly assigned and copending application U.S. Ser. No. 10/448,968 (CHOUDHARY, ET AL.) May 30, 2003, entitled “System and Method for User Driven Interactive Application Integration,” a manner of using information from a first portlet in performing an action in a second portlet, referred to as “Click-to-Action” is disclosed. When a user selects one of the “Click-to-Action” icons or controls displayed in a Source portlet, he or she sees a menu of actions invocable with respect to target portlets on the page that can process the properties (i.e., data items) that the icon or control is associated with. The user selects one of the actions from the menu, which results in a request being delivered to a Target portlet to perform the given action. The “Click-to-Action” feature described in the CHOWDHURY, ET AL. patent application, however, does not provide a way to persistently couple portlets.
In another commonly-assigned copending patent application, U.S. Ser. No. 10/292,074 (DUNNE, ET AL.) Nov. 12, 2002, a tool for allowing a user or administrator to couple portlets through a web-based interface was described. The DUNNE, ET AL. application describes the creation of “wires.” A wire, as the term is used in the DUNNE, ET AL. application and herein, is a persistent association between a property in a source portlet and an action in a target portlet. When an event occurs that affects the property of a wire, the action associated with that property is triggered.
Although DUNNE, ET AL. tool significantly enhanced a user's ability to custom-configure a portal interface, one drawback to the tool was that a user would have to first interact with the portlets on the portal page itself, or in complex cases read additional documentation, then navigate to a separate tool interface display in order to couple or de-couple portlets. In a moderately complex portal, a user might have to switch back and forth between the portal and the tool interface a number of times in order to complete the user's configuration of the portal, which can be inconvenient.
What is needed, therefore, is a system and method for allowing a user to couple portlets without having to switch back and forth between a tool interface display and the portal itself.